Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add proof-of-concept for handling module types in Source Typed #1467

Closed

Conversation

zhaojj2209
Copy link
Contributor

Part of #1399

This PR adds a basic implementation of module type handling in Source Typed, using the rune module as an example. Source Typed is now able to properly handle types for runes, as well as throw errors when attempting to import a name that does not exist in the module.

Summary of implementation:

  • A map of names available in the runes module to their respective type information is created (see runeTypes.ts). The map also contains an extra prelude attribute, which contains the types shared by variables and functions in the module (in this case, Rune and AnimatedRune). The type information in the map are in the form of Source Typed code strings (constant/function/type alias declarations) which can be evaluated by the Source Typed type checker. To hide the actual implementation of the module, the code in the map are placeholder code that only serves to save the correct types in the type environment when the code is evaluated. The types for the variables/functions are retrieved from the rune module documentation.
  • When encountering import statements that import from the rune module, the Source Typed type checker will fetch the prelude code + code for the names imported for that module, and evaluate the code as a program string. Following evaluation, the correct types for the module names will be saved in the type environment for use in the rest of the program.

Sample screenshots:
Screenshot 2023-08-12 at 14 37 58
Screenshot 2023-08-12 at 14 36 56

To test this PR, link local js-slang to local frontend and write runes module code in any of the Source Typed chapters. Some unit tests have also been written.

To expand this proof-of-concept to an implementation that is extensible to all modules, the following needs to be done:

  • The map of module names to types (runeTypes.ts) should be shifted to the modules repo. All future module type maps should be written in the modules repo instead and made available for fetching (e.g. as JSON files).
  • The TODO: Add logic for fetching module type declarations map from modules repo code should be replaced with logic that fetches the module maps from the module repo as and when needed.

When writing module type maps, note the following:

  • The map must contain a prelude attribute that contains code for the types shared by variables and functions in the module. If there are no shared types, an empty string should be provided.
  • Code in the map should be placeholder code that hides the actual module implementation and only provides the correct types needed.
  • The module map must contain all names in the module, else the NameNotFoundInModule error will be thrown for names that are not in the module map.
  • Types in the map must be consistent with the modules documentation.

Limitations in the current approach:

  • Since the placeholder value for runes is the string 'Rune', type errors will not be thrown if attempting to assign type string to the rune. This is an unfortunate result of hiding the module implementation using Source primitive values. One possible solution would be to add special placeholder type for modules, however this will likely require more extensive changes to Source Typed, and is currently out of scope for this PR.

@coveralls
Copy link

coveralls commented Aug 12, 2023

Pull Request Test Coverage Report for Build 5999214362

  • 37 of 40 (92.5%) changed or added relevant lines in 3 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.04%) to 82.715%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/errors/typeErrors.ts 8 9 88.89%
src/typeChecker/typeErrorChecker.ts 28 30 93.33%
Totals Coverage Status
Change from base Build 5995455758: 0.04%
Covered Lines: 10803
Relevant Lines: 12619

💛 - Coveralls

@martin-henz martin-henz marked this pull request as draft September 3, 2023 02:39
@martin-henz
Copy link
Member

Yes as a proof-of-concept this is interesting. I don't think we should start hard-wiring module types into js-slang as in https://github.com/source-academy/js-slang/pull/1467/files#diff-2e2aa2db6619eec1be92cd4c227f51bafd0c3e8a0ba28a58c105e5e08944ec5d

Instead, the module should provide the types to be used in Source §x Typed.

We need to take a closer look at this next year.

@martin-henz
Copy link
Member

Closing this issue in favor of source-academy/modules#217

@martin-henz martin-henz closed this Sep 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

3 participants